Collaboration servers provide interaction between users, typically within an organization. For example, an electronic mail server, such as Microsoft Exchange, provides electronic mail delivery, shared calendaring, and other services to users within a corporation or other enterprise. Using a collaboration server, users can send email back and forth, schedule meetings, store contact lists, and so forth.
Email and other forms of communication, such as public folder and message forum posts, often involve conversations. In a conversation, one or more participants create messages on a particular topic. Each message after the original message that starts the conversation is a reply to either the original or a later message in the conversation. For example, a participant Alicia may send a message or post to a forum regarding a topic such as politics. A participant Bob may then reply to Alicia's message. Another participant Carl may then reply to either Alicia or Bob's message, and Alicia and Bob may make additional replies based on replies to their respective messages. The result is a large tree of messages that make up a conversation on the particular topic.
When a new participant enters a conversation, he/she often wants to go back and read what contributions previous participants have made to the conversation. For example, the new participant may want to avoid adding redundant information that other participants have already contributed. Conversations can be very large, and the new participant may open not only the latest message, but also all of the previous messages in the conversation. It is not unusual for a conversation to contain 50 or more messages.
One of the most frequent problems for email and collaboration servers is scalability. Email and collaboration servers often provide services to thousands of users, many of whom may simultaneously log on and attempt to access the services. The high level of concurrent use can exceed the server's available resources. The amount of information that can be held in memory often determines the number of users to which a server can scale, because accesses to secondary storage devices (e.g., hard drives) often incur delays that are substantially greater than memory (e.g., 100×). Thus, when application developers build email and collaboration servers, it is often a design goal to reduce the frequency of accesses of secondary storage devices.
Conversations compound the problem. When a conversation participant accesses a message in a conversation and begins reading through the conversation, the participant may request many messages in the conversation stored by the server. For example, a user may view the 50 previous messages in a particular conversation. Multiply this by the thousands of users that may be accessing the server simultaneously and the requests may quickly exceed the amount of messages that the server can keep in memory or the number of input/output (I/O) requests that the server can handle. Thus, the server will inevitably end up accessing slower, secondary storage devices, which in turn reduces the number of users to which the email and collaboration server can provide services. The users of the server may also notice a degraded level of service based on the exhaustion of resources at the server.